跑敏捷會不會花很多時間在開會？

前陣子有人問我，你們跑敏捷會不會花很多時間在開會上？我說如果是跑 Scrum 的話它有一些固定的會議，我們來看看 Scrum Guide 是怎麼描述的。

Scrum 的活動

All events are time-boxed events, such that every event has a maximum duration.

這裡一開始就說了每一個活動都是 time-boxed (時間盒)。所以說就算要開會，也應該有個最大的上限，我們來算算吧。

一個 Sprint 最多 4 個星期，也就是說 4 個星期內應該就有東西可以看到。而一個 Sprint 裡面的活動有：

• Sprint Planning
  • 以一個月的 Spring 來說最多不超過 8 小時，所以如果是一星期的 Sprint 最多就是 2 小時。
• Daily Scrum (Daily Meeting / Daily Standup Meeting)
  • 每天不超過 15 分鐘
• Sprint Review
  • 以一個月的 Spring 來說最多不超過 4 小時，所以如果是一星期的 Sprint 最多就是 1 小時。
• Sprint Retrospective
  • 以一個月的 Spring 來說最多不超過 3 小時，所以如果是一星期的 Sprint 最多就是 45 分鐘。

我們用一個星期的 Sprint 來計算一下。
Sprint Planing 2 小時，Daily 15 分鐘 * 5 = 75 分鐘(0.25 * 5 = 1.25 小時)，Sprint Review 1 小時， Sprint Retrospective 45 分鐘(0.75小時)，所以總共 5 小時。

如果以一週上班 5 天，每天 8 小時，一週工時 40 小時來說，扣掉 5 小時的會議， 還有 35 小時的工作時間。

花這些時間值得嗎？

雖然說，在需求明確下，多這 5 個小時的產出是可以很驚人的，但如何才能明確需求呢？那就是在開始寫程式前所花的時間，如果以瀑布式開發的方法來說，就是先把需求和設計都做完後再交付給開發人員。但這要花多少時間呢？如果在需求和外在環境都不變的情況下，我相信完整釐清需求和完美的設計所花的時間一定會比 Scrum 開會所需要花費的總時間來的少，至少不用頻繁的做 context switch (中文翻上下文交換/環境切換)，也就是開會，寫程式，開會，寫程式。

沒有對錯只有選擇

你喜歡花些時間開會溝通把需求釐清清楚，還是都不要開會，拿到規格文件就開始開工作呢？